fix(runtime): enable SSR remote-entry retry and URL failover - #4968

🦋 Changeset detected

Latest commit: 108c924

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Thanks for adding Node.js SSR remote-entry retry support. The overall direction looks good, but I found a few retry edge cases that should be addressed before merging.

1. ESM modules that fail while linking remain in esmModuleCache.

For example:

remoteEntry -> chunk-a -> chunk-b

If the first fetch of chunk-b fails, chunk-a remains cached as an errored SourceTextModule. Retrying the entry with ?retryCount=1 still resolves chunk-a to the same URL, so the retry
reads the poisoned cache entry and fails with:

ERR_VM_MODULE_LINK_FAILURE: request for './chunk-a.mjs' resolved to an errored module

The error is then reclassified as ScriptExecutionError, so the retry cannot recover even after chunk-b becomes available. Could we evict modules from esmModuleCache when linking or
evaluation fails, and add a test covering a transient failure in a transitive ESM dependency?

2. Execution errors are only treated as non-retryable on the initial attempt.

Once loadEntryError has started scriptRetry, a retry attempt that throws ScriptExecutionError is caught by scriptRetry like any other error, and the remaining attempts still run. This
can execute a partially failing remote multiple times and contradicts the changeset’s “execution errors non-retryable” behavior.

Could scriptRetry immediately rethrow ScriptExecutionError and preserve the original error? A test where the initial load has a network failure and the first retry has an execution failure
would cover this case.

3. Invalid URLs are currently classified as network errors.

A failure from new URL(url) is a configuration/URL validation error, not a transport failure. Classifying it as ScriptNetworkError sends it through RUNTIME_008 and retry-plugin, even
though retrying cannot repair the URL and may replace the useful ERR_INVALID_URL with a generic retry-abandoned error.

I verified that the existing SDK/runtime-core tests and builds pass. The additional ESM cache and execution-error-during-retry cases above both reproduce consistently.

@2heal1 Thanks for the detailed review. I addressed all three retry edge cases:

1. Failed ESM modules are now evicted from esmModuleCache when linking or evaluation fails, including transitive dependencies. Added a regression test for a transient transitive chunk failure.

2. scriptRetry now immediately rethrows ScriptExecutionError during retry attempts and preserves the original error. Added coverage for an initial network failure followed by an execution failure.

3. Invalid URLs now propagate the original URL validation error instead of being classified as ScriptNetworkError/RUNTIME_008 or entering the retry flow. Added SDK and runtime-core coverage.

108c924